終於！讓我們歡呼一下！來賓請掌聲鼓勵！
如果有紅地毯的現在可以舖下去了！歡迎歡迎！
我們正式邀請「大數據(Big Data)」這位嘉賓出場！

Big Data~ Big Data~ 天下古今幾多之文章，假汝之名以行！

最早來由眾說紛紜，直到2010年由IBM開始頻繁將其使用為專業用語，接著逐步發展至今。可以說從2010年「大數據(Big Data)」這詞才正式降臨登場(我就不說「誕生」這二個字了)。而這8年間，掀起了一股「大數據(Big Data)」熱潮，大眾開始不分青紅皂白的，只要和數據沾點邊，就可以脫口而出：Big! Data~~~~

然而，我從這角度切入，你就知道這專有名詞，真的該被這樣解讀才對。

前面提到了我團隊夥伴做出的「抗菌洗手乳」和「親子遊園票券」，很有感覺吧？對吧對吧？可能還差啤酒尿布一些，但概念很相近了是吧？好......那我要來告訴大家真相了......

在我們抽樣十萬多筆的交易裡，它只出現了5次，嗯對，就是5次。

而且我們條件還不是讓它們被一起購買，而是先後曾經購買。縱使有時間先後，做的並非【順序型態分析(Sequential Pattern Analysis)】，也不是單純的單筆訂單【關聯分析(Associative Analysis) 】。而是決定一個時間區間內，相同一名會員，購買過的所有商品當作一車購物籃；換句話說，我們不是用單筆訂單的所有商品當作一個購物車，而是用單個會員某段時間區間內購買的所有商品當作一個購物車。

而縱使條件已經放寬到這種地步，Support值仍是非常可憐的0.0000488。

可是Confidence卻是83%和100%，Lift值不用多說是爆表的高，而且最重要的是...結果是能被解讀且能說服人的。所以縱使只有5次，我們還是把該次的分析報告放了這個內容進去，眾人皆感耳目一新。

它的商品關聯性極高，但出現的頻率卻堪稱稀有，這才是所謂「大數據(Big Data)」的精髓！

在足夠大量的資料及數據中，才能探究、發現出極其稀有的結果；換句話說，因為這樣真實的存在、這個有價值的存在，實在太過稀有、太過少量，我們必須擁有極大量的資料，才能收集足夠證據，也才能說服大家「這件事真的存在」。這才是小馬我認為的「大數據(Big Data)」。

各位Google一下「什麼是Big Data？」，於是會發現很多說Big Data要具備3V、4V等等，未來發展成10V甚至220V(喂~這樣要帶變壓器嗎~)，我都不會太意外，對我而言，這是標準的：為賦新辭強說愁。

業界講了非常多描述大數據的形容詞，就以4V來說：

1. Volume：巨大的資料量
2. Variety：資料形式的多元化，數據文字、影像訊息、瀏覽行為等等
3. Velocity：傳輸速度快速
4. Veracity：資料的真實與正確性

我不由得想反問，然後呢？常說【「啤酒尿布」是大數據(Big Data)結論之最佳範本】，上面這四個V，哪裡能讓我和「啤酒尿布」做上任何聯想？4V甚至沒提到任何分析過程！

因此我們首先可以知道，大家很常講「啤酒尿布是透過Big Data運算出來」的這句話，事實上，似是而非！問題不是發生在4V(縱使它是強說愁的概念罷了)，但「啤酒尿布...Big Data...」這句話本身更大有毛病。

嚴格講起來，啤酒尿布的結論，是透過【資料分析(Data Analysis)】這步驟裡，經常使用的其中一種分析方式叫做【關聯分析(Association)】，做出來的，平心而論，到此為止，皆暫時與【大數據(Big Data)】毫無相關。

除非，做出這結論的Walmart有類似這樣的補充：「在過去，我們經常執行【關聯分析(Association)】，但都沒有發現過這樣的結論。一直到近年來交易成長、數據增加，我們才終於發現這兩者的商品關聯。」除非如此，這整件事才算得上跟【大數據(Big Data)】有關。

否則，啤酒尿布就僅只是一個正常執行的數據分析所帶來的一個絕妙結果，而根本與【大數據(Big Data)】沒有關係。

有了前面15天資料處理的說明，相信各位更能理解這個結論。
明天小馬要來挑戰一下：清楚定義【大數據(Big Data)】。

大數據 番外篇1

以下提到「大數據」或「Big Data」字眼，
請當作某種「嘲諷」的概念看待，
而非我心目中正確定義及用法。

這邊先稍微解釋一下Tableau的介面，
資料讀入之後，每個欄位可以拉成橫縱軸，
也可以設計成篩選器，例如下圖右上角的篩選器(多選)。

小馬我第一次感受到「大數據」的威力，是發生在PK事件之後。

PK當時，還是用Excel當作Tableau的底階數據；
隨著該場PK贏得漂亮，加上長官支持，漸漸在IT部門打通了關。

終於，我們不再是用Excel檔做事，
而終於可以連進資料庫裡面，直接使用資料庫的資料，
而這個步驟，更促成了我前公司的資料倉儲計畫。

嗯!?
因此推動了資料倉儲計畫？
所以當時還沒有資料倉儲？
那小馬你連的資料庫…是什麼資料庫……
相信有資料倉儲背景的，看到這應該替我捏了把冷汗。

對，我直接連進了 AP Server 。

剛開始使用都還沒任何人覺得有問題，直到某天，
我們要計算會員的RFM，區間需要涵蓋兩年的交易資料。
當時還沒有透過任何的SQL工具處理，就只是Tableau下公式。

而我們運用了兩年的資料，Tableau做成的版面，的那個篩選器，
每個動作，例如將多選篩選器打勾起來、將多選取消打勾，
這樣的簡單動作......

必須等2小時才會有結果。

不做資料採礦，妄想資料清洗完，
直接做資料分析，會有什麼結果？
現在你知道了。

這就是直接運用原始資料的下場之一。

記得當初Tableau年度發表會上，
(當年的Tableau大會還不到100人，不像這次有1700人。)
我找原廠描述這個狀況，原廠還覺得不置可否。

因為Tableau不斷強調它們就是可以處理Big Data的軟體，
卻不知道還真有人直接拿了原始的Big Data來跑看看啊！
甚至那只不過是兩年的交易資料啊！

好的，先撇除【有mining的工要先做】這件事，
看到這，有專業背景的一定會問：
「小馬，會不會是硬體的資源分配問題或是頻寬問題？」

不會，頻寬跟主機硬體首先確認過沒問題，
至於 AP Server 的資源分配......
不用說，我相信，全部都給我們用了。

因為就在我們當天從早上用到下午的某個時間點，
終於，IT的AP部門聯絡上了我們......

「你們是不是有在讀交易資料？」AP人員問，口吻略顯氣急敗壞。
「對呀~」小馬天真貌。
「就是你們！快斷線！！！」
「怎麼了嗎？」小馬不知輕重地問著。

「全台灣三百間門市都不能結帳，因為你們把資源全佔據了！」

然後我們就有資料倉儲了。